-
Notifications
You must be signed in to change notification settings - Fork 15.3k
[BPF] Remove unused weak symbol __bpf_trap #166003
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
Nikita Popov reported an issue ([1]) where a dangling weak symbol __bpf_trap is in the final binary and this caused libbpf failing like below: $ veristat -v ./t.o Processing 't.o'... libbpf: elf: skipping unrecognized data section(4) .eh_frame libbpf: elf: skipping relo section(5) .rel.eh_frame for section(4) .eh_frame libbpf: failed to find BTF for extern '__bpf_trap': -3 Failed to open './t.o': -3 In llvm, the dag selection phase generates __bpf_trap in code. Later the UnreachableBlockElim pass removed __bpf_trap from the code, but __bpf_trap symbol survives in the symbol table. Having a dangling __bpf_trap weak symbol is not good for old kernels as seen in the above veristat failure. Although users could use compiler flag '-mllvm -bpf-disable-trap-unreachable' to workaround the issue, this patch fixed the issue by removing the dangling __bpf_trap. [1] llvm#165696
f6f3c28 to
fd849b2
Compare
|
cc @tuliom Would be good to confirm whether this fixes the issues you saw on RHEL 8. |
| if (GV->getName() == BPF_TRAP) | ||
| SawTrapCall = true; | ||
| } else if (Op.isSymbol()) { | ||
| if (const MCSymbol *Sym = Op.getMCSymbol()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will always fire an assertion:
MCSymbol *getMCSymbol() const {
assert(isMCSymbol() && "Wrong MachineOperand accessor");
return Contents.Sym;
}But isMCSymbol() is always false since isSymbol() is true instead.
What's the right fix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used Op.isSymbol() as a possible target but running bpf selftest, the branch with Op.isSymbol() never to be true, at least when running linux kernel bpf selftests.
Let me double check whether this branch isSymbol() is really necessary or not.
|
The BPF_TRAP is created as So BPF_TRAP will be used as a global in instructions. So the branch should be considered as dead code and can be removed. WDYT? |
In [1], the symbol __bpf_trap (macro BPF_TRAP) is removed if it is not used in the code. In the discussion in [1], it is found that the branch "if (Op.isSymbol())" is actually always false. Remove it to avoid confusion. [1] llvm#166003
In [1], the symbol __bpf_trap (macro BPF_TRAP) is removed if it is not used in the code. In the discussion in [1], it is found that the branch "if (Op.isSymbol())" is actually always false. Remove it to avoid confusion. [1] #166003
…166440) In [1], the symbol __bpf_trap (macro BPF_TRAP) is removed if it is not used in the code. In the discussion in [1], it is found that the branch "if (Op.isSymbol())" is actually always false. Remove it to avoid confusion. [1] llvm/llvm-project#166003
Nikita Popov reported an issue ([1]) where a dangling weak symbol __bpf_trap is in the final binary and this caused libbpf failing like below:
In llvm, the dag selection phase generates __bpf_trap in code. Later the UnreachableBlockElim pass removed __bpf_trap from the code, but __bpf_trap symbol survives in the symbol table.
Having a dangling __bpf_trap weak symbol is not good for old kernels as seen in the above veristat failure. Although users could use compiler flag
-mllvm -bpf-disable-trap-unreachableto workaround the issue, this patch fixed the issue by removing the dangling __bpf_trap.[1] #165696